Re: 8lgm's SCO "at" hole

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: der Mouse: "Re: Race conditions"
• Previous message: John Nemeth: "Re: 8lgm's SCO "at" hole"
• Maybe in reply to: Justin Mason: "8lgm's SCO "at" hole"

> 
> >> select(getdtablesize(), &readfds, &writefds, &exceptfds, &timeout);
> > getdtablesize() doesn't exist on all systems and can return very very
> > large numbers on systems that have dynamically allocated file tables.
> 
> That was (part of) my reaction too...but that's not the real point.
> Think about what the first note was talking about: MAXPATHLEN
> increasing, so in the future getwd() might construct and (try to)
> return a string longer than the statically allocated buffer whose size
> was fixed when the application was compiled: essentially, a clash
> between compiling now and executing in the future after system changes.
> 
> Now go back and look at that select() call again, with that in mind :-)
> 

Consider this code snippet:

	fd_set readfds, writefds, exceptfds;
	struct timeval timeout;
	...
	select(getdtablesize(), &readfds, &writefds, &exceptfds, &timeout);

The type fd_set depends on FD_SETSIZE (see /usr/include/sys/types.h on SunOS 4.x).
If getdtablesize() returns a value larger than FD_SETSIZE, the select() call will
do "out of bounds" accesses, e.g. it will (probably) end up somewhere in writefds
when accessing the "high" descriptors in readfds.

• Next message: der Mouse: "Re: Race conditions"
• Previous message: John Nemeth: "Re: 8lgm's SCO "at" hole"
• Maybe in reply to: Justin Mason: "8lgm's SCO "at" hole"